> The RFCs specify that you must never respond to an ICMP request with a > broadcast. However, this may work with UDP echo ports on hosts with > defective behavior of the sort we've just been noting. When doing broadcast pings (for network debugging), I've regularly noticed a number of the, umm, less-than-solid IP stacks make this mistake. If a network is half Suns and half PCs, the PCs often respond with a source broadcast address. I'm sure they're doing this because the ICMP ECHO code simply swaps the source and destination addresses, sets the ICMP type, and returns the packet. As someone else pointed out though, with ICMP ECHO (ping), you won't get storms because the return packet is an ICMP ECHOREQUEST, a completely different type of packet. The relevant question, I think, is with respect to the RFC defining the UDP echo service; does it say that it should never respond with a broadcast address? Below is the COMPLETE RFC (RFC 862). I think it's safe to say that the "correct" behavior with respect to broadcasts is unspecified. ----- Begin RFC ----- This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Echo Protocol are expected to adopt and implement this standard. A very useful debugging and measurement tool is an echo service. An echo service simply sends back to the originating source any data it receives. TCP Based Echo Service One echo service is defined as a connection based application on TCP. A server listens for TCP connections on TCP port 7. Once a connection is established any data received is sent back. This continues until the calling user terminates the connection. UDP Based Echo Service Another echo service is defined as a datagram based application on UDP. A server listens for UDP datagrams on UDP port 7. When a datagram is received, the data from it is sent back in an answering datagram. ----- End RFC -----